With the emergence of 3G mobile telephony, new packet-based communication technologies have been developed for communicating multimedia content. For example, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technologies support wireless multimedia telephony services involving packet-switched communication of data representing images, text, documents, animations, audio files, video files, etc., in addition to traditional circuit-switched voice calls.
Recently, a network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard, to provide multimedia services for mobile clients in the packet domain. IMS is generally a platform for enabling services based on IP transport, more or less independent of the access technology used and basically not restricted to any limited set of specific services.
A specification for session setup has been defined called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261 et al), which is an application-layer control (signalling) protocol for creating, modifying and terminating sessions over a packet-switched logic. SIP is generally used by IMS networks for supporting multimedia services.
FIG. 1 illustrates schematically a basic network structure for providing multimedia services by means of an IMS service network. It should be noted that the figure is greatly simplified and only shows a selection of network nodes helpful to understand the context of the present invention. A mobile terminal A is connected to a first radio access network 100 and may communicate with another mobile terminal B connected to a second radio access network 102, in a packet-switched communication session S. Terminal A may also communicate with a fixed terminal or computer or a content server delivering some multimedia content to the terminal, such as a piece of music, a film or a game.
An IMS network 104 is connected to the first radio access network 100 and handles the session S and other multimedia services for terminal A. In fact, the IMS network 104 receives and processes any service requests or data from the user of terminal A. In this figure, a corresponding similar IMS network 106 handles the session S and other multimedia services for terminal B, and the two IMS networks 104 and 106 may be controlled by different operators. Terminals A and B may of course alternatively be connected to the same access network and/or belong to the same IMS network.
The illustrated session S is managed by a node called S-CSCF (Serving Call Session Control Function) 108 assigned to terminal A in the IMS network 104, and the used multimedia service is enabled and executed by an application server 110. Further, a main database element HSS (Home Subscriber Server) 112 stores subscriber and authentication data as well as service information, among other things, that the application server 110 and S-CSCF 108 can retrieve for executing services for clients.
IMS network 104 also contains the nodes I-CSCF (Interrogating Call Session Control Function) 114 receiving messages from other IMS networks such as network 106, and P-CSCF (Proxy Call Session Control Function) 116 acting as an entry point for clients connected to access network 100. Each application server supports one or more specific multimedia services and typically contains several “service units” or “applications” for different types of services.
Examples of services defined for IMS networks include “Instant Messaging” (IM) “Push-to-talk over Cellular” (PoC) and “Presence”, all using SIP signalling for controlling sessions. Instant Messaging provides for transmission of relatively short messages between terminals involving different types of media. PoC enables a group of mobile users to communicate collectively by pushing a button or the like to open a channel in order to talk or send multimedia content. Presence services basically make data of a client available to other clients.
In multimedia services, the term “presence” generally represents a dynamic and variable state profile of a client, involving the publishing of presence data of a client, which can also be used to control other services. Presence data basically defines the “state” of a client and his/her equipment in any predefined respect. Thus, the term “presence” should be understood in a broad sense, and the following exemplary client states may make up the presence data:                A personal status, e.g. available, busy, in a meeting, on holiday, etc.        A terminal status, e.g. switched on/off, engaged, out of coverage, etc.        The geographic location of the client/terminal.        Terminal capabilities, e.g. functionality for SMS, MMS, chat, IM, video, etc.        Terminal selections, e.g. call forwarding, language, etc.        Other client information, e.g. interests, occupations, personal characteristics, moods, personal logos, logo depending on the current mood, etc.        
This type of information is continually stored in application servers in the IMS network, if required, based on so-called “publications of events” received from clients or their access network, whenever any presence data or other data for a client is introduced, changed or deleted. According to some services, a client may thus also subscribe for selected presence data or other data of one or more other users, e.g. according to a list of users, which is also handled by an application server in the IMS network.
A SIP message called “SIP PUBLISH” is generally used by clients to send dynamic data (e.g. presence data) to application servers in the IMS network. Another SIP message called “SIP SUBSCRIBE” is used by clients to subscribe for such dynamic data of other clients, as handled by service units in application servers.
A “client state” represents the maintenance of client-related information in an application server during a limited time period as determined by a pre-set expiry time, sometimes referred to as TTL (Time To Live). Such client-related information may relate to published client data or a client's subscription for data of other users.
However, these services may result in a large amount of messages that are sent from clients towards the IMS network, in particular for Presence services. For example, a terminal may be obliged to send a series of SIP PUBLISH messages to different service units in application servers immediately after the terminal has been registered in the IMS network after being powered-on, in order to publish updated client data.
As the client state for published client data or a data subscription also has an expiry time period or TTL, the published data or data subscription becomes invalid as the time expires. The expiry time may be set by the client or the application server, typically one hour in the Presence case. In the current service implementation and according to the different standards of IETF, 3GPP and OMA, the data publication or subscription must be frequently refreshed in order to maintain the data/subscription valid in the application server, even if the data/subscription is not changed during this period. A refresh message may be conveyed in an SIP PUBLISH message.
The SIP PUBLISH message can in fact be used in four different cases, namely: 1) initiating new data, 2) refreshing data (i.e. confirming that earlier initiated data continue to be valid), 3) modifying data, and 4) terminating data no longer valid.
A conventional procedure for maintaining published client data in an application server will now be described with reference to a block diagram shown in FIG. 2. A client terminal A is currently connected to an access network (not shown) in order to communicate with an IMS network 200. As shown in the figure, the IMS network 200 includes a session managing node 202 (e.g. S-CSCF), plural application servers 204 and an HSS 206.
In a first step 2:1, e.g. after being powered-on, terminal A sends a registration request message (i.e. SIP REGISTER) to session manager 202 to become registered as an active terminal in the IMS network 200. Next, terminal A is registered in the HSS 206 according to conventional routines not further described here, as indicated in a step 2:2. In order to maintain the registration in IMS network 200, the terminal is then obliged to refresh the registration by regularly sending “re-register” messages or the like to session manager 202, e.g. every 30-60 minutes, as generally indicated by dashed arrows 2:3.
During this ongoing routine, typically immediately after being registered, terminal A may also send one or more client data publication messages, (e.g. SIP PUBLISH), to one or more service units in the application servers 204, as generally illustrated by a step 2:4. The received client data is then stored in the application server(s) 204, and will remain valid during a time-out period (or TTL), typically set to 30 or 60 minutes.
In order to maintain the published data valid in the application server(s) 204, the terminal must refresh the published data by regularly sending “re-publish” messages as the time-out period expires, generally indicated by plural dashed arrows 2:5, even if the data has not changed. As a result, a terminal may have to send a series of data refreshing messages to different service units in application servers each time their respective validity periods (TTL) expire.
When the terminal 200 is eventually turned off, a “de-register” message is finally sent to the session manager 202, in a step 2:6. Typically, the terminal is also obliged to send a “de-publish” message, not shown, to each concerned service unit in the application server(s) 204 to inactivate published data. Otherwise, the data will only become invalid when the time-out periods expire, as from the last refresh message was sent, resulting in irrelevant active client states after the client has logged off. Time-out periods for data are therefore set relatively short, however resulting in frequent refresh messages.
Basically, the same procedure would be used when the client sends a subscription request for data of other clients, as described above. In that case, the message of step 2:4 would be a subscription request message (e.g. SIP SUBSCRIBE) resulting in the activation of another client state for the subscription in a service unit in an application server 204. Furthermore, the refreshing messages of step 2:5 would be a frequently-sent “re-subscribe” message in order to maintain this client state.
A client may of course have a plurality of different active services involving data publication duties and subscriptions of data, each requiring regular refresh messages from the client terminal in order to be continued. However, there are some obvious load problems associated with having the client's terminal frequently sending re-publish and/or re-subscribe messages to a multitude of service units in application servers, as explained below.
The European Patent Application 05445042.4 discloses a solution for avoiding the sending of frequent refresh messages from a terminal for a service involving published data, when the data has not changed. In this solution, existing routines for maintaining a client registration (i.e. the sending of re-registration messages) is utilised for refreshing also published data.
The present invention addresses the problem of sending numerous publication or subscription messages as well as regular refreshing messages, that must be conveyed to each of a multitude of different services. Concerning reducing the number of refreshing messages, the present invention may be regarded as an alternative or complementary solution with respect to the above-mentioned EP 05445042.4. Thus, if a client has a multitude of various active client states in different service units in application server(s), the burden of sending such service messages can be significant for the terminal, and precious bandwidth in the air interface is also consumed. This situation is illustrated in FIG. 3.
A client terminal A is connected to a mobile access network 300 and has activated a plurality of services in an IMS network, which are illustrated as functional service units 304. For example, service 1 may be IM, service 2 may be PoC, and service 3 may be a Presence service, and so forth, as implemented in one or more application servers as described above. The following example illustrates a conventional procedure for sending refresh messages for the active services, although it is valid for other service messages as well such as initial and remove.
In a first illustrated step 3:1, terminal A sends a first refresh message (e.g. SIP PUBLISH) directed to service 1 at 304:1, which is first received by a serving session manager 302 (e.g. S-CSCF) in the IMS network. Session manager 302 then accordingly routes the refresh message to service 1 in a following step 3:2. Next, terminal A sends another refresh message directed to service 2 at 304:2 to session manager 302 in step 3:3, that is accordingly routed to service 2 in a following step 3:4. A third refresh message is also sent from terminal A to session manager 302 in step 3:5, directed to service 3 at 304:3, that is routed to service 3 in a final illustrated step 3:6.
It should be noted that each step 3:1, 3:3, 3:5 of sending a refresh message over the air interface may involve a plurality of radio messages communicated over the air interface, e.g. for establish a Radio Access Bearer RAB and other control signalling including acknowledging messages in either direction. When several multimedia services are involved, this behaviour thus results in a considerable load on resources in both the terminal and the mobile access network 300, particularly the scarce radio bandwidth.
In the case of subscription for client data, an information delivery server has been proposed for the distribution of information to clients regarding other clients, referred to as a “Resource List Server” RLS in IMS networks. The client information in question may of course include any of the above-described types of presence data or similar.
FIG. 4 illustrates an RLS 400 in a multimedia service network, providing information to a client terminal A on a group of other clients B, C and D. Terminal A is connected to a mobile access network 402 and all messages between terminal A and RLS 400 are routed over a serving session manager 404. It is assumed that clients B, C and D continuously publish data to their application servers 406B, 406C and 406D, respectively, as illustrated by arrows p. Application servers 406B-D may belong to other multimedia service networks or the same network as the RLS 400.
The RLS 400 is connected to a user list server 408 maintaining various user lists such as phone books, contact groups, ad hoc groups or the like. In a first illustrated step 4:1, terminal A sends a request for data on clients B,C,D which are indicated by a reference to a predefined user list, in accordance with a specific service, e.g. the Presence service. According to SIP, this message may then be configured as: SIP SUBSCRIBE (event:Presence,list=1).
In response thereto, RLS 400 retrieves the users and their application servers from user list server 408, according to the received list reference, in a step 4:2. Thereafter, RLS 400 sends a request for data, in a “subscribe” message, to each of the application servers 406B-D for their respective client. This behaviour is sometimes referred to as an “exploder” function for clients. RLS 400 then receives the desired data as notifications from them in response, as generally illustrated by steps 4:3, 4:4 and 4:5, respectively. In a final step 4:6, RLS 400 sends a notification to terminal A, in response to the subscription request 4:1, containing desired data on all clients B-D in the list. This procedure must however be repeated if data is to be collected according to other services, e.g. PoC or IM.
In WO 2005/088949, a solution is described where the amounts of transmitted data and delays can be reduced by a combined push and pull mechanism. In this solution, information does not have to be fetched for every user when information is requested by a client, as this information has already been received and stored continuously by using ongoing network subscriptions, and is therefore immediately available from a user database.
However, it is desirable to avoid the problem of sending numerous service messages for several different services such as publish and subscribe messages as well as regular refreshing messages, in order to relieve both the client's terminal and network resources of this burden, particularly with respect to the air interface.